The present invention relates in general to distributed data processing systems and more particularly to a system and method for distributing application data across distributed databases of dissimilar formats.
Many legacy enterprise applications store data in their own proprietary database formats. As the needs of business users have evolved, application software development has evolved accordingly, and one path of such evolution is the trend to move away from proprietary database architectures and towards standard relational or object-based database models.
In a relational database, data are stored in multi-dimensional tables. Each table has multiple rows and columns populated with information that describe the relationship between the data elements. Use of a relational database application, instead of a proprietary database, has the obvious advantage of opening the data to the vast array of relational database query and data manipulation tools that are pervasive among enterprise computing developers. It also allows the business user and the application itself to take advantage of the proven reliability of a commercial enterprise database engine. A relational database is not tied to a specific record and file format; customers"" writing tools that interface with the database will be significantly less impacted when changes and additions are made to the database by the application developers.
Many existing software applications still work with data in their own proprietary format, thus making that data inaccessible for the vast majority of new software tools. Furthermore, many users are reluctant to replace their legacy software, because they have invested heavily in the existing software application and related tools. Users are also concerned with an abrupt transition from a legacy database that has been functioning without problem to a brand new system that may present some unforseen problems. Consequently, software developers are forced to continue support of these legacy database systems that are no longer efficient or flexible.
In view of the foregoing, it is therefore an object of the present invention to provide a system and method that enable multiple database models to be supported by a given software application simultaneously.
It is yet another object of the present invention to provide a system and method for preparing a legacy database system for migration to a new software application database system of dissimilar format.
The foregoing objectives are achieved by a distributed architecture defined by a storage subsystem that receives, from a business object, data objects encapsulating the data to be stored. The storage subsystem is responsible for distributing the data objects to converters that reform the data into the format necessary for the data object""s attributes to be stored in a database of a given type.
Business objects represent a software application that needs to view or manipulate data stored in the software application""s database. Business objects create data objects via a factory object. Factory objects are abstract factories that produce data objects of different types. Data objects represent some logical grouping of information that is applicable to an application. For instance, a data object representing a person for an address book application could contain all relevant information about that person that the address book tracks. Storage objects present the interface to software applications or business objects. Data access objects, or converters, have the responsibility of converting data of a data object into a different format that can be used to store the data object""s encapsulated information into a database. Database interface objects receive data from the data access objects and store that data into physical databases.
Business objects have methods defined to interface software applications. When a software application is ready to write data into a database, the business object requests creation of a data object from a factory object. The data object is created and the business object then populates the data object with information from the software application. After the data object is filled with information, the business object requests the storage object to store the information in this data object into a plurality of external databases and passes this data object to the storage object. The storage object notifies local and remote data access objects about the data, and these data access objects then store the data object into their respective databases through a database interface. The data can be stored in different formats into different databases.
This system provides a path of smooth migration between two database models, and can support a greater number of database models. Databases of different formats can exist and be updated in parallel, giving users the flexibility to access the data as they see fit. Users can then migrate from a proprietary format to an industry standard format as their needs and schedules permit. The system also helps to free the development team from legacy database format restriction and allows the database to evolve as new features and functionalities are added. The legacy database could retain its current structure while features are added to the new relational database. This would allow the users to use the new features of the relational database without compromising their existing tools.